Network Functions Virtualisation (NFV) aims to transform the way that network operators architect networks by evolving standard Internet Technology (IT) virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in a variety of NFV infrastructure network nodes and in end-user premises.
For traditional high availability systems, such as telecom network elements, the service availability is quite difficult to operate from end-to-end. All applications or services in traditional systems are designed with the same level of service availability or resilience without any differentia. The actual “needed” availability and reliability of the services has not been considered in implementation. For example, the web browsing service, could tolerate 20-30 seconds of service interruption because of failure without impacting the user experience. However, the current system provides only one level of resilience typically with 1-10 seconds failure recovery time. Thus, over-provisioning system resource has been assigned to the service with low service availability requirement. Meanwhile, other user services may be considerably more time sensitive, for example communication by Voice over the Internet Protocol (VoIP).
One of the key design objectives in NFV has been specified as the end-to-end availability of telecommunication services. The NFV frameworks shall ensure that not all services need to be “built to the peak,” but Service Level Agreements (SLAs) can be defined and applied according to given resiliency classes. The service reliability and availability requirements for a few service availability levels have been specified in NFV. The service availability level is not only given the indication of the priority of service, but also given the service recovery time requirement and priority for failure recovery.
However, there is no specified method concerning how the service reliability and availability differentia to different service types or groups is operated and managed. In addition, there is not specified how end-to-end service availability with service flow differentia is operated. Neither is there provided any mechanism for end-to-end service availability with service flow differentia management.
In some alternative solutions, a software defined availability (SDA) differentia feature has been suggested for the private cloud. However, the solution is not applicable to end-to-end service availability management and is only able to be used in the particular user case with a single application or service in a Virtual Machine (VM).
There are three problems in current system in the operation and management (O&M) of service availability.
Firstly, the conventional telecom system cannot provide service availability differentia to different service type or service group and provides only one level of service availability and reliability typically with 5-10 seconds failure recovery time. Thus, over-provisioning of the system resource has been assigned to the service with low service availability requirement.
Secondly, when mechanisms of reliability and availability have been configured and the equipment has been shipped to a service provider, the service provider cannot change the configuration of service reliability and availability.
Finally, there is no end-to-end mechanism for the operating of end-to-end service availability with service flow differentia in current system. Neither there is any provided mechanism for end-to-end service availability with service flow differentia management.
It would thus be desired to provide a mechanism for service reliability and availability differentia and operating and managing the end-to-end service reliability and availability in a flexible manner. Thereby, the service providers may be enabled to deploy the “needed” service availability and reliability to any service type or user group, dynamically.